Summary

Two identical conditions appeared verbatim in three sibling dispatchers in ProcedureCall:

• argument_metadata[:type_name] == "XMLTYPE" || argument_metadata[:data_type] =~ /XMLTYPE/ — at add_argument, add_return_variable, and return_variable_value
• argument_metadata[:tmp_table_name] (presence check guarding the "TABLE / PL/SQL TABLE type defined inside package" branch) — same three sites

Collapse each into a single private predicate (xmltype_argument?, tmp_table_argument?) so the rule lives in one place. The longest line in the affected dispatchers (~88 chars) becomes a 35-char predicate call.

def xmltype_argument?(metadata)
  metadata[:type_name] == "XMLTYPE" || metadata[:data_type] =~ /XMLTYPE/
end

def tmp_table_argument?(metadata)
  metadata[:tmp_table_name]
end

Scope

This is intentionally narrow. The three case argument_metadata[:data_type] dispatchers themselves are not restructured — a broader Strategy-style refactor was considered and rejected for this PR because the lines-of-code cost did not pay for the structural change. Only the verbatim duplications are removed here.

Diff stat: lib/plsql/procedure_call.rb | 20 ++++++++++++++------ (+14 / -6).

Test plan

• bundle exec rspec — 468 examples, 0 failures, 1 pre-existing pending (Oracle 9.2 indexed-by-binary-integer skip)
• ruby -c lib/plsql/procedure_call.rb passes
• No remaining occurrences of the verbatim XMLTYPE check or the bare argument_metadata[:tmp_table_name] presence check (string interpolations of :tmp_table_name in generated SQL are out of scope and remain)

🤖 Generated with Claude Code